Skip to content

Add support for bytes key btree indices#4733

Open
Centril wants to merge 1 commit intomasterfrom
centril/range-compat-bytes-key
Open

Add support for bytes key btree indices#4733
Centril wants to merge 1 commit intomasterfrom
centril/range-compat-bytes-key

Conversation

@Centril
Copy link
Copy Markdown
Contributor

@Centril Centril commented Mar 31, 2026

Description of Changes

Add support for btree indices where the keys are encoded byte strings for e.g., multi-column indices of no-unbounded-types (arrays and strings) that aren't floats.

The main interesting stuff in this PR is in bytes_key.rs which defines RangeCompatBytesKey, a type that is derived from BytesKey, by converting little-endian encoded integers to big-endian. Signed integers are now also supported, but floats are not.

API and ABI breaking changes

None

Expected complexity level and risk

2?

Testing

A proptest order_in_bsatn_is_preserved is now adjusted and enabled to exercise the ordering of RangeCompatBytesKey.

Copy link
Copy Markdown
Collaborator

@joshua-spacetime joshua-spacetime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think more testing is needed for this patch.

let suffix_len = suffix_types.len();

match &self.idx {
BTreeBytesKey8(_) => Self::bounds_from_bsatn_bytes_key(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we need to handle UniqueBTreeBytesKey* here too?

Comment on lines +239 to +243
pub(super) fn from_bsatn_prefix_and_endpoint(
prefix: &[u8],
prefix_types: &[ProductTypeElement],
endpoint: &[u8],
range_type: &AlgebraicType,
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prefix is the fixed (non-range) part of the scan right? But the entire range key itself could still be a prefix of the index? In which case there's an implicit suffix with MIN and MAX bounds that we're omitting which is not correct.

Currently I believe if you have a 3-column index on (u64, u64, u64), prefix=5 and endpoint=1 effectively becomes the range [(5,1,0), (5,1,0)].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants